GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>SQL-Injection</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading">SQL-Injection</h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr">SQL-Injection (dt. SQL-Einschleusung) ist das Ausnutzen einer <a href="Sicherheitsl%C3%BCcke_(Software)" class="mw-redirect" title="Sicherheitslücke (Software)">Sicherheitslücke</a> in Zusammenhang mit <a href="SQL" title="SQL">SQL</a>-Datenbanken. Die Sicherheitslücke entsteht durch einen Programmierfehler in einem Programm, das auf die Datenbank zugreift. Durch diesen Programmierfehler kann ein Angreifer Datenbankbefehle einschleusen und abhängig vom Einzelfall weitere Daten aus der Datenbank auslesen, Daten unberechtigt ändern oder löschen oder sogar die Kontrolle über den kompletten Datenbankserver übernehmen.

<div class="mw-heading mw-heading2"><h2 id="Voraussetzungen">Voraussetzungen</h2></div>

Ein erfolgreiches Ausnutzen einer SQL-Injection erfordert:

<ul><li>eine SQL-Datenbank, die angegriffen wird, zum Beispiel <a href="MySQL" title="MySQL">MySQL</a>, <a href="Microsoft_SQL_Server" title="Microsoft SQL Server">Microsoft SQL Server</a>, <a href="Db2" title="Db2">Db2</a></li>

<li>ein Anwendungsprogramm, in das Angreifer Daten eingeben können, zum Beispiel eine <a href="Login_(Informationstechnik)" title="Login (Informationstechnik)">Loginmaske</a>, eine Produktsuche in einem Onlineshop oder ein Kontaktformular im Web</li>

<li>dass das Anwendungsprogramm diese Daten an die Datenbank weiterreicht</li>

<li>einen Programmierfehler in dem Anwendungsprogramm, beim Weiterreichen der Daten</li></ul>

Der Programmierfehler besteht darin, dass das Anwendungsprogramm die Eingabedaten nicht als reine Daten an die Datenbank weiterreicht, sondern aus diesen Daten die Datenbankabfrage erzeugt. Dadurch kann ein Angreifer versuchen, Teile der Datenbankabfrage gezielt zu steuern.

In der Datenbankabfragesprache SQL haben einige Zeichen eine besondere Bedeutung, insbesondere:

<ul><li>der <a href="Apostroph" title="Apostroph">Apostroph</a>, um Textdaten zu umschließen</li>

<li>das <a href="Anf%C3%BChrungszeichen" title="Anführungszeichen">Anführungszeichen</a>, um Textdaten zu umschließen (nur einige Datenbanken)</li>

<li>der <a href="Umgekehrter_Schr%C3%A4gstrich" class="mw-redirect" title="Umgekehrter Schrägstrich">umgekehrte Schrägstrich</a> (Backslash), um das nachfolgende Zeichen nicht als besonderes Zeichen zu interpretieren</li>

<li>das <a href="Semikolon" title="Semikolon">Semikolon</a>, um einen Datenbankbefehl von dem nächsten Datenbankbefehl zu trennen</li>

<li>ein doppelter <a href="Bindestrich" class="mw-redirect" title="Bindestrich">Bindestrich</a>, um den Rest der Zeile zu ignorieren (<a href="Kommentar_(Programmierung)" title="Kommentar (Programmierung)">Kommentar</a>)</li></ul>

Dokumentenorientierte <a href="NoSQL" title="NoSQL">NoSQL</a> Datenbanken können ebenfalls von diesem Sicherheitsproblem betroffen sein:

<ul><li>die geschweiften und eckigen <a href="Klammer_(Zeichen)#Klammern_im_Internationalen_Phonetischen_Alphabet" title="Klammer (Zeichen)">Klammern</a>, welche ein <a href="JSON" title="JSON">JSON</a> Objekt bzw. Array umschließen</li></ul>

Diese Zeichen verwendet ein Angreifer gezielt, um den Angriff durchzuführen.

<div class="mw-heading mw-heading2"><h2 id="Beispiel">Beispiel</h2></div>

Ein Beispiel für eine SQL-Abfrage, die in einem <a href="Redaktionssystem" title="Redaktionssystem">Redaktionssystem</a> nach Artikeln aus einer bestimmten Kategorie sucht, ist:

</pre></div></dd></dl>

Diese Abfrage hat folgende Bestandteile:

<ul><li>Die großgeschriebenen Wörter sind Schlüsselwörter in SQL und haben eine feste Bedeutung.</li>

<li>Die kleingeschriebenen Wörter sind die Namen von Tabellen, Zeilen oder Spalten in der Datenbank.</li>

<li>Text innerhalb von einfachen Anführungszeichen ist feststehender Text.</li></ul>

Der Text „gesuchte Kategorie“ stellt hier nur einen Platzhalter dar, an dieser Stelle der Datenbankabfrage muss die jeweils gesuchte Kategorie eingetragen werden. Solange die gesuchte Kategorie keins der oben erwähnten Sonderzeichen enthält, könnte sie direkt in die Beispielabfrage eingesetzt werden.

Wenn die gewünschte Kategorie jedoch zum Beispiel <a href="Rock_'n'_Roll" class="mw-redirect" title="Rock 'n' Roll">Rock_’n’_Roll</a> ist und damit einen Apostroph enthält, führt ein naives Ersetzen des Platzhalters zu dieser SQL-Abfrage:

</pre></div></dd></dl>

Auffällig ist hier die Doppelbedeutung des Apostroph: einerseits als Begrenzer, andererseits als wörtlich gemeintes Zeichen. Diese Doppelbedeutung ist für Menschen ersichtlich, aus Sicht der Datenbank ist diese Anfrage jedoch nicht sinnvoll interpretierbar, da die Abfrage als <code>kategorie = 'Rock '</code> interpretiert wird, gefolgt von einem Wort <code>n</code> und dem weiteren Text <code>' Roll'</code> in Apostrophen. Mit dem Wort <code>n</code> kann die Datenbank nichts anfangen und wird für diese Abfrage daher eine Fehlermeldung zurückgeben.

Eine SQL-Injection besteht nun darin, dass der Angreifer durch gezielte Wahl der Eingabedaten die Datenbankabfrage so verändert, dass sie zwar noch eine gültige Struktur hat, aber eine andere Bedeutung. So führt zum Beispiel der scheinbar unsinnige Suchbegriff <code>asdfasdf' OR id < 100 OR kategorie = 'sdfgsdfg</code> zu dieser Datenbankabfrage:

<dl><dd><div class="mw-highlight mw-highlight-lang-sql mw-content-ltr" dir="ltr"><pre>SELECT id, titel, artikeltext FROM artikel WHERE kategorie = 'asdfasdf' OR id < 100 OR kategorie = 'sdfgsdfg';

</pre></div></dd></dl>

Diese Abfrage ist aus Sicht der Datenbank völlig korrekt, sie enthält 3 einzelne Bedingungen, von denen mindestens eine wahr sein muss. Die erste und dritte Bedingung haben in diesem Beispiel nur die Aufgabe, dass die SQL-Abfrage weiterhin <a href="Syntax#Syntax_formaler_Sprachen" title="Syntax">wohlgeformt</a> ist, und es ist unwahrscheinlich, dass es in der Datenbank tatsächlich Kategorien dieses Namens gibt. Daher bleibt als einzig relevante Bedingung <code>id < 100</code> übrig. Aus der ursprünglichen SQL-Abfrage, die nur Artikel aus einer bestimmten Kategorie liefert, ist durch geschickte Wahl des Suchbegriffs eine strukturell andere SQL-Abfrage geworden, die nun die Artikel anhand ihrer ID sucht, unabhängig von der Kategorie.

Durch diese geänderte SQL-Abfrage kann ein Angreifer möglicherweise Daten aus der Datenbank sehen, die nicht für ihn bestimmt sind. Durch andere gezielte Suchbegriffe kann der Angreifer möglicherweise Daten in der Datenbank ändern oder löschen, je nach Einzelfall.

Der Programmierfehler besteht bei einer SQL-Injection darin, den Suchbegriff 1:1 in die Datenbankabfrage zu übernehmen, ohne die besondere Bedeutung des Apostroph und ähnlicher Zeichen zu berücksichtigen.

<div class="mw-heading mw-heading2"><h2 id="Vorgang">Vorgang</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Veränderung_von_Daten">Veränderung von Daten</h3></div>

Auf einem <a href="Webserver" title="Webserver">Webserver</a> befindet sich das Script find.cgi zum Anzeigen von Artikeln. Das Script akzeptiert den Parameter „ID“, welcher später Bestandteil der SQL-Abfrage wird. Folgende Tabelle soll dies illustrieren:

<th>

</th>

<th style="background:#ABCDEF">Erwarteter Aufruf

</th></tr>

<tr>

<th style="background:#ABCDEF">Aufruf

</th>

<td><code>http://webserver/cgi-bin/find.cgi?ID=42</code>

</td></tr>

<tr>

<th style="background:#ABCDEF">Erzeugtes SQL

</th>

<td><code>SELECT author, subject, text FROM artikel WHERE ID=42;</code>

</td></tr>

<tr>

<th>

</th>

<th style="background:#ABCDEF">SQL-Injection

</th></tr>

<tr>

<th style="background:#ABCDEF">Aufruf

</th>

<td><code>http://webserver/cgi-bin/find.cgi?ID=42;UPDATE+USER+SET+TYPE="admin"+WHERE+ID=23</code>

</td></tr>

<tr>

<th style="background:#ABCDEF">Erzeugtes SQL

</th>

<td><code>SELECT author, subject, text FROM artikel WHERE ID=42;UPDATE USER SET TYPE="admin" WHERE ID=23;</code>

</td></tr></tbody></table>

Dem Programm wird also ein zweiter SQL-Befehl untergeschoben, der die Benutzertabelle modifiziert.

<div class="mw-heading mw-heading3"><h3 id="Datenbank-Server_verändern">Datenbank-Server verändern</h3></div>

Auf einem Webserver findet sich das Script search.aspx zum Suchen nach Webseiten. Das Script akzeptiert den Parameter „keyword“, dessen Wert später Bestandteil der SQL-Abfrage wird. Folgende Tabelle soll dies illustrieren:

<th>

</th>

<th style="background:#ABCDEF">Erwarteter Aufruf

</th></tr>

<tr>

<th style="background:#ABCDEF">Aufruf

</th>

<td><code>http://webserver/search.aspx?keyword=sql</code>

</td></tr>

<tr>

<th style="background:#ABCDEF">Erzeugtes SQL

</th>

<td><code>SELECT url, title FROM myindex WHERE keyword LIKE '%sql%'</code>

</td></tr>

<tr>

<th>

</th>

<th style="background:#ABCDEF">SQL-Injection

</th></tr>

<tr>

<th style="background:#ABCDEF">Aufruf

</th>

<td><code>http://webserver/search.aspx?keyword=sql'+;GO+EXEC+cmdshell('shutdown+/s')+--</code>

</td></tr>

<tr>

<th style="background:#ABCDEF">Erzeugtes SQL

</th>

<td><code>SELECT url, title FROM myindex WHERE keyword LIKE '%sql' ;GO EXEC cmdshell('shutdown /s') --%'</code>

</td></tr></tbody></table>

Hier wird der eigentlichen Abfrage ein weiterer Befehl angehängt. Die zwei Bindestriche <code>--</code> kommentieren das Hochkomma als Überbleibsel der eigentlichen Anfrage aus, womit es ignoriert wird. Die nun generierte Abfrage ermöglicht das Ausführen eines Windows-Prozesses, hier illustriert durch das erzwungene Herunterfahren des Servers (sofern der Prozess Administratorrechte hat). Aber auch Daten oder Ähnliches lassen sich dadurch erzeugen (am Beispiel Microsoft SQL Server).

<div class="mw-heading mw-heading3"><h3 id="Ausspähen_von_Daten">Ausspähen von Daten</h3></div>

Auf manchen SQL-Implementationen ist die <code>UNION</code>-Klausel verfügbar. Diese erlaubt es, mehrere <code>SELECT</code>s gleichzeitig abzusetzen, die dann eine gemeinsame Ergebnismenge zurückliefern. Durch eine geschickt untergeschobene <code>UNION</code>-Klausel können beliebige Tabellen und Systemvariablen <a href="Aussp%C3%A4hen_von_Daten" title="Ausspähen von Daten">ausgespäht</a> werden.

<th>

</th>

<th style="background:#ABCDEF">Erwarteter Aufruf

</th></tr>

<tr>

<th style="background:#ABCDEF">Aufruf

</th>

<td><code>http://webserver/cgi-bin/find.cgi?ID=42</code>

</td></tr>

<tr>

<th style="background:#ABCDEF">Erzeugtes SQL

</th>

<td><code>SELECT author, subject, text FROM artikel WHERE ID=42;</code>

</td></tr>

<tr>

<th>

</th>

<th style="background:#ABCDEF">SQL-Injection

</th></tr>

<tr>

<th style="background:#ABCDEF">Aufruf

</th>

<td><code>http://webserver/cgi-bin/find.cgi?ID=42+UNION+SELECT+login,+password,+'x'+FROM+user</code>

</td></tr>

<tr>

<th style="background:#ABCDEF">Erzeugtes SQL

</th>

<td><code>SELECT author, subject, text FROM artikel WHERE ID=42 UNION SELECT login, password, 'x' FROM user;</code>

</td></tr></tbody></table>

Das <code>x</code> beim <code>UNION SELECT</code> ist nötig, weil alle mit <code>UNION</code> verknüpften <code>SELECT</code>s die gleiche Anzahl von Spalten haben müssen. Der Angreifer kann die Anzahl der Spalten herausfinden, indem er <code style="white-space:nowrap">ID=42 order by x--</code> anhängt. Wenn die Seite beispielsweise bei x = 8 normal lädt, aber bei x = 9 eine Fehlermeldung oder andere Seite zeigt, dann ist die Spaltenanzahl 8.

Ist der Datenbankserver fehlerhaft konfiguriert und hat beispielsweise ein aktuell mit der Datenbank verbundener Benutzer, über den die SQL-Injection abgesetzt werden soll, Zugriff auf Systemdatenbanken, so kann der Angreifer über eine einfache SQL-Syntax wie <code>Systemdatenbank.SystemtabelleMitTabellenAuflistung</code> auf die Systemtabellen zugreifen und sämtliche Tabellen einer bestimmten Datenbank auslesen. Dadurch kann er wichtige Informationen erhalten, um weitere Angriffe durchzuführen und tiefer in das System einzudringen.

Bei MySQL-Datenbanksystemen werden diese Systeminformationen in der Datenbank <code>information_schema</code><a href="#cite_note-1">[1]</a> verwaltet. Das nachfolgende Beispiel zeigt, wie bei einer Abfrage mit 3 Ergebnisspalten die Struktur sämtlicher zugreifbarer Datenbanken in Erfahrung gebracht werden kann.

<th>

</th>

<th style="background:#ABCDEF">Erwarteter Aufruf

</th></tr>

<tr>

<th style="background:#ABCDEF">Aufruf

</th>

<td><code>http://webserver/cgi-bin/find.cgi?ID=42</code>

</td></tr>

<tr>

<th style="background:#ABCDEF">Erzeugtes SQL

</th>

<td><code>SELECT author, subject, text FROM artikel WHERE ID=42;</code>

</td></tr>

<tr>

<th>

</th>

<th style="background:#ABCDEF">SQL-Injection

</th></tr>

<tr>

<th style="background:#ABCDEF">Aufruf

</th>

<td><code>http://webserver/cgi-bin/find.cgi?ID=42+UNION+SELECT+'Datenbank',+'Tabelle',+'Spalte'+ UNION+SELECT+table_schema,+table_name,+column_name+FROM+information_schema.columns+ WHERE+NOT+table_schema='information_schema';#%20</code>

</td></tr>

<tr>

<th style="background:#ABCDEF">Erzeugtes SQL

</th>

<td><code>SELECT author, subject, text FROM artikel WHERE ID=42 UNION SELECT 'Datenbank', 'Tabelle', 'Spalte' UNION SELECT table_schema, table_name, column_name FROM information_schema.columns WHERE NOT table_schema='information_schema';# ;</code>

</td></tr></tbody></table>

Einige Datenbanksysteme bieten weiterhin die Möglichkeit, Dateien über eine Anfrage zurückzugeben. Hierüber können in Kombination mit oben genannten Techniken und soweit der Pfad bekannt ist, beliebige Dateien, auf die der Datenbankprozess Zugriff hat, ausgelesen werden.

Ein ähnlicher Aufruf in einer <a href="MongoDB" title="MongoDB">MongoDB</a> NoSQL Datenbank könnte so aussehen.

<th>

</th>

<th style="background:#ABCDEF">Erwarteter Aufruf

</th></tr>

<tr>

<th style="background:#ABCDEF">Aufruf

</th>

<td><code>http://webserver/cgi-bin/find.cgi?ID=42</code>

</td></tr>

<tr>

<th style="background:#ABCDEF">Erzeugtes NoSQL

</th>

<td><code>db.users.find({ userID: 42 });</code>

</td></tr>

<tr>

<th>

</th>

<th style="background:#ABCDEF">NoSQL-Injection

</th></tr>

<tr>

<th style="background:#ABCDEF">Aufruf

</th>

<td><code>http://webserver/cgi-bin/find.cgi?ID['$ne']=</code>

</td></tr>

<tr>

<th style="background:#ABCDEF">Erzeugtes NoSQL

</th>

<td><code>db.users.find({ userID: { '$ne': undefined } });</code>

</td></tr></tbody></table>

<code>$ne</code> ist der Operator für „ungleich“, die Abfrage gibt die Benutzer zurück, deren Benutzername nicht leer ist, d. h. alle Benutzer.

<div class="mw-heading mw-heading3"><h3 id="Einschleusen_von_beliebigem_Code">Einschleusen von beliebigem Code</h3></div>

Eine weniger bekannte Variante stellt gleichzeitig die potenziell gefährlichste dar. Wenn der Datenbankserver die Kommandos <code>SELECT … INTO OUTFILE</code> beziehungsweise <code>SELECT … INTO DUMPFILE</code> unterstützt, können diese Kommandos dazu benutzt werden, Dateien auf dem <a href="Dateisystem" title="Dateisystem">Dateisystem</a> des Datenbankserver abzulegen. Theoretisch ist es dadurch möglich, falls das Bibliotheksverzeichnis des Betriebssystems oder des Datenbankservers für denselben beschreibbar ist (wenn dieser zum Beispiel als <a href="Root-Account" class="mw-redirect" title="Root-Account">root</a> läuft), einen beliebigen Code auf dem System auszuführen.

<div class="mw-heading mw-heading3"><h3 id="Zeitbasierte_Angriffe">Zeitbasierte Angriffe</h3></div>

Wenn der Datenbankserver <a href="Benchmark" title="Benchmark">Benchmark</a>-Funktionen unterstützt, kann der Angreifer diese dazu nutzen, um Informationen über die Datenbankstruktur in Erfahrung zu bringen. In Verbindung mit dem if-Konstrukt sind der Kreativität des Angreifers kaum Grenzen gesetzt. Das Kopieren von Datenbankinhalten dauert allerdings wesentlich länger.

Das folgende Beispiel benötigt auf einem <a href="MySQL" title="MySQL">MySQL</a>-Datenbankserver mehrere Sekunden, falls der gegenwärtige User <a href="Root_Account" class="mw-redirect" title="Root Account">root</a> ist:

<div class="mw-highlight mw-highlight-lang-sql mw-content-ltr" dir="ltr"><pre>SELECT IF( USER() LIKE 'root@%', BENCHMARK(100000,SHA1('test')), 'false');

</pre></div>

Verwandt dazu sind Boolesche Angriffe, die durch Boolesche Abfragen versuchen, Datenbankinhalte zu extrahieren.

<div class="mw-heading mw-heading3"><h3 id="Erlangen_von_Administratorrechten">Erlangen von Administratorrechten</h3></div>

Bei bestimmten Datenbankservern, wie dem <a href="Microsoft_SQL_Server" title="Microsoft SQL Server">Microsoft SQL Server</a> bis zur Version 2000, wurden Stored Procedures wie Xp_cmdshell automatisch angeboten, die unter anderem dazu missbraucht werden können, Kommandos mit den Rechten des SQL-Serverprogramms auszuführen. Neuere Versionen des Microsoft SQL Server haben diese Funktion standardmäßig deaktiviert. Diese Möglichkeit konnte dazu benutzt werden, um zum Beispiel eine <a href="Betriebssystem-Shell" class="mw-redirect" title="Betriebssystem-Shell">Shell</a> auf dem angegriffenen <a href="Computer" title="Computer">Rechner</a> zu starten.

<div class="mw-heading mw-heading3"><h3 id="Verwundbarkeiten_innerhalb_des_Datenbankservers">Verwundbarkeiten innerhalb des Datenbankservers</h3></div>

Manchmal existieren Verwundbarkeiten auch innerhalb der Datenbanksoftware selbst. So erlaubte zum Beispiel die PHP-Funktion mysql_real_escape_string() im <a href="MySQL" title="MySQL">MySQL</a> Server einem Angreifer, SQL Injection-basierende Angriffe basierend auf Unicode-Zeichen selbst dann auszuführen, wenn die Benutzereingaben korrekt maskiert wurden. Dieser Fehler wurde in der Version 5.0.22 am 24. Mai 2006 behoben.

<div class="mw-heading mw-heading3"><h3 id="Blinde_SQL-Injection">Blinde SQL-Injection</h3></div>

Von einer blinden SQL-Injection wird gesprochen, wenn ein Server keine deskriptive Fehlermeldung zurückliefert, aus der hervorgeht, ob der übergebene <a href="Abfragesprache" title="Abfragesprache">Query</a> erfolgreich ausgeführt wurde oder nicht. Anhand verschiedenster Kleinigkeiten wie etwa leicht unterschiedlicher Fehlermeldungen oder charakteristisch unterschiedlicher Antwortzeiten des Servers kann ein versierter Angreifer häufig dennoch feststellen, ob ein Query erfolgreich war oder einen Fehler zurückmeldet.

<div class="mw-heading mw-heading2"><h2 id="Gegenmaßnahmen">Gegenmaßnahmen</h2></div>

Um SQL-Injections zu verhindern, dürfen vom Benutzer eingegebene Daten nicht ohne Weiteres in eine SQL-Anweisung eingebaut werden. Eingabedaten können auf die Eigenschaften erwarteter Werte geprüft werden. So bestehen deutsche Postleitzahlen beispielsweise nur aus Ziffern.

<div class="mw-heading mw-heading3"><h3 id="Grundidee_von_Prepared_Statements">Grundidee von Prepared Statements</h3></div>

Der sicherste Weg ist jedoch, die Daten überhaupt vom SQL-Interpreter fernzuhalten.<a href="#cite_note-2">[2]</a> Dabei kann man auf das Kappen der Eingabe verzichten. Die Technik dazu sind gebundene Parameter in <a href="Prepared_Statement" title="Prepared Statement">Prepared Statements</a>. Dabei werden die Daten als Parameter an einen bereits kompilierten Befehl übergeben. Die Daten werden somit nicht interpretiert und eine SQL-Injection verhindert. <a href="Gespeicherte_Prozedur" title="Gespeicherte Prozedur">Stored Procedures</a> bieten dagegen keinen generellen Schutz vor SQL-Injection, insbesondere dann nicht, wenn der SQL-Code der Funktion nicht bekannt ist.

Doch auch auf Seiten des Datenbankservers lassen sich Sicherheitsvorkehrungen treffen. So sollten die Benutzer, mit denen sich eine Webanwendung beim Datenbankserver authentifiziert, nur die Privilegien besitzen, die er tatsächlich benötigt. So können zumindest einige der möglichen Angriffe unwirksam werden.

Hat ein Betreiber eines Webservers keine Kontrolle über die Anwendungen, kann durch Einsatz von <a href="Web_Application_Firewall" title="Web Application Firewall">Web Application Firewalls</a> (WAF) zumindest teilweise verhindert werden, dass SQL-Injection-Schwachstellen ausgenutzt werden können. Unabhängig von der Kontrolle über die Anwendungen kann ein Betreiber eines Webservers durch den gezielten Einsatz einer WAF die Sicherheit zusätzlich erhöhen, da viele WAFs neben abwehrenden auch prophylaktische Maßnahmen anbieten.

Es ist nicht schwer, bestehende Programme so umzubauen, dass SQL-Injections nicht mehr möglich sind. Das hauptsächliche Problem der meisten Programmierer ist fehlendes Wissen über diese Art von Angriffen. Nachfolgend einige Beispiele, um die Angriffe abzuwehren.

Die naive, aber falsche Idee, eine SQL-Abfrage mit beliebigen Eingabedaten anzureichern, sieht in den meisten Programmiersprachen so aus:

<div class="mw-highlight mw-highlight-lang-python3 mw-content-ltr" dir="ltr"><pre># gefährlicher Code, enthält die Sicherheitslücke SQL-Injection

sql = "SELECT spalte1 FROM tabelle WHERE spalte2 = '" + eingabedaten + "';"

</pre></div>

Die doppelten Anführungszeichen gehören hier zur Programmiersprache, die einfachen Anführungszeichen gehören zu SQL. Wenn die Eingabedaten selbst auch einfache Anführungszeichen enthalten können, ist eine SQL-Injection möglich. Um das zu verhindern, ist die Idee, die SQL-Anfrage und die Daten zu trennen. Das <code>:eingabedaten</code> im folgenden Code ist ein Platzhalter für die eigentlichen Eingabedaten. Diese werden in einem zweiten Schritt bei der Abfrage mittels <code>db.query</code> an die Datenbank übergeben. Die Trennung von SQL und Eingabedaten verhindert eine SQL-Injection.

<div class="mw-highlight mw-highlight-lang-python3 mw-content-ltr" dir="ltr"><pre>sql = "SELECT spalte1 FROM tabelle WHERE spalte2 = :eingabedaten;"

query = db.query(sql, eingabedaten=eingabedaten)

</pre></div>

<div class="mw-heading mw-heading3"><h3 id="Python">Python</h3></div>

In Python gibt es mehrere Möglichkeiten, mit einer Datenbank zu kommunizieren. Eine davon ist <a href="SQLAlchemy" title="SQLAlchemy">SQLAlchemy</a>. Um hierbei SQL-Injection zu entgehen, sollte man rohe SQL-Befehle vermeiden, sofern diese durch Form- oder URL Anfragen manipuliert werden könnten. Nachfolgend ist ein solches Beispiel zu sehen:

<div class="mw-highlight mw-highlight-lang-python3 mw-content-ltr" dir="ltr"><pre>db.engine.execute("SELECT * FROM table")

</pre></div>

Stattdessen wird dazu geraten die internen Funktionen und Methoden von SQLAlchemy zu nutzen, wie z. B. die Folgenden:<a href="#cite_note-3">[3]</a>

<div class="mw-highlight mw-highlight-lang-python3 mw-content-ltr" dir="ltr"><pre>session.query(Order).get(order_id)

session.query(Order).filter(Order.status == 'active')

</pre></div>

<div class="mw-heading mw-heading3"><h3 id="Visual_Basic_(ADOdb)">Visual Basic (ADOdb)</h3></div>

In <a href="Visual_Basic_Classic" title="Visual Basic Classic">Visual Basic</a> gibt es einfache Command-Objekte, mit denen diese Probleme vermieden werden können.

Anstatt

<div class="mw-highlight mw-highlight-lang-vbnet mw-content-ltr" dir="ltr"><pre>cn.Execute "SELECT spalte1 FROM tabelle WHERE spalte2 = '" & spalte2Wert & "'"

</pre></div>

sollte Folgendes verwendet werden:

<div class="mw-highlight mw-highlight-lang-vbnet mw-content-ltr" dir="ltr"><pre>Dim cmd As ADODB.Command, rs as ADODB.Recordset

With cmd

Set .ActiveConnection = cn

Set .CommandType = adCmdText

.CommandText = "SELECT spalte1 FROM tabelle WHERE spalte2 = ?"

.Parameters.Append .CreateParameter("paramSp2", adVarChar, adParamInput, 25, spalte2Wert) '25 ist die max. länge

Set rs = .Execute

End With

</pre></div>

<div class="mw-heading mw-heading3"><h3 id="Delphi">Delphi</h3></div>

Seit der BDE kennen die Querys Parameter. Die Syntax ist bei verschiedenen Komponentensammlungen nicht immer identisch aber ähnlich.

Anstatt …

<div class="mw-highlight mw-highlight-lang-delphi mw-content-ltr" dir="ltr"><pre>function TDatabase.GetData(ParameterID: Integer): Integer;

var

Qry: TQuery;

begin

Result := 0;

Qry := TQuery.Create;

try

Qry.SQL.Text := 'SELECT F_DATA FROM T_BLUBB WHERE ID = ' + IntToStr(ParameterID);

Qry.Open;

Result := Qry.FieldByName('F_DATA').AsInteger;

finally

Qry.Free;

end;

end;

</pre></div>

… sollte definitiv mit Parametern gearbeitet werden:

var

Qry: TQuery;

begin

Result := 0;

try

Qry.ParamByName('PI').AsInteger := ParameterID;

Qry.Open;

finally

Qry.Free;

end;

end;

</pre></div>

<div class="mw-heading mw-heading3"><h3 id="Microsoft_.NET_Framework_–_C#_(ADO.NET)">Microsoft .NET Framework – C# (ADO.NET)</h3></div>

Im <a href=".Net-Framework" title=".Net-Framework">.Net-Framework</a> gibt es einfache Objekte, mit denen solche Probleme umgangen werden können.

Anstatt

<div class="mw-highlight mw-highlight-lang-csharp mw-content-ltr" dir="ltr"><pre>SqlCommand cmd = new SqlCommand("SELECT spalte1 FROM tabelle WHERE spalte2 = '"

+ spalte2Wert + "';");

</pre></div>

sollte Folgendes verwendet werden:

<div class="mw-highlight mw-highlight-lang-csharp mw-content-ltr" dir="ltr"><pre>string spalte2Wert = "Mein Wert";

SqlCommand cmd = new SqlCommand("SELECT spalte1 FROM tabelle WHERE spalte2 = @spalte2Wert;");

cmd.Parameters.AddWithValue("@spalte2Wert", spalte2Wert);

</pre></div>

Eine SQL-Injection kann leicht durch eine bereits vorhandene Funktion verhindert werden. In <a href="Java_(Programmiersprache)" title="Java (Programmiersprache)">Java</a> wird zu diesem Zweck die PreparedStatement-Klasse verwendet (<a href="Java_Database_Connectivity" title="Java Database Connectivity">JDBC</a>-Technologie) und die Daten unsicherer Herkunft werden als getrennte Parameter übergeben. Um die Daten von der SQL-Anweisung zu trennen, wird der Platzhalter „?“ verwendet.

Anstatt

<div class="mw-highlight mw-highlight-lang-java mw-content-ltr" dir="ltr"><pre>Statement stmt = con.createStatement();

ResultSet rset = stmt.executeQuery("SELECT spalte1 FROM tabelle WHERE spalte2 = '"

</pre></div>

sollte Folgendes verwendet werden:

<div class="mw-highlight mw-highlight-lang-java mw-content-ltr" dir="ltr"><pre>PreparedStatement pstmt = con.prepareStatement("SELECT spalte1 FROM tabelle WHERE spalte2 = ?");

pstmt.setString(1, spalte2Wert);

ResultSet rset = pstmt.executeQuery();

</pre></div>

Der Mehraufwand an Schreibarbeit durch die Verwendung der PreparedStatement-Klasse kann sich außerdem durch einen Performancegewinn auszahlen, wenn das Programm das PreparedStatement-Objekt mehrfach verwendet.

In <a href="PHP" title="PHP">PHP</a> steht für Datenbankzugriffe die Bibliothek <a href="PHP_Data_Objects" title="PHP Data Objects">PHP Data Objects</a> zur Verfügung.

Beispiel ohne Prepared Statement:

<div class="mw-highlight mw-highlight-lang-php mw-content-ltr" dir="ltr"><pre>$dbh->exec("INSERT INTO REGISTRY (name, value)

VALUES (".$dbh->quote($name,PDO::PARAM_STR).", ".$dbh->quote($value,PDO::PARAM_INT).")");

</pre></div>

Beispiel mit Prepared Statement:

<div class="mw-highlight mw-highlight-lang-php mw-content-ltr" dir="ltr"><pre>$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");

$stmt->bindParam(':name', $name);

$stmt->bindParam(':value', $value);

</pre></div>

Bis zur PHP-Version 5.3 gab es die Konfigurationsoption „magic_quotes_gpc“. War diese auf „on“ gestellt, wurden von außen kommende Benutzereingaben automatisch maskiert. Manche Skripte nutzen Funktionen wie etwa <code>addslashes()</code><a href="#cite_note-4">[4]</a> oder <code>mysql_real_escape_string()</code><a href="#cite_note-5">[5]</a>. Das heißt, dass bereits allen relevanten Zeichen in den Benutzereingaben durch so genannte Magic Quotes<a href="#cite_note-6">[6]</a> ein <a href="Backslash" title="Backslash">Backslash</a> vorangestellt wurde und nun durch die Escape-Funktion erneut ein Backslash vorangestellt wird. Somit werden die Benutzereingaben verfälscht und man erhält beispielsweise anstatt eines einfachen Anführungszeichens ein Anführungszeichen mit vorangestelltem Backslash (<code>\"</code>). Auch aus Gründen der <a href="Plattformunabh%C3%A4ngigkeit" title="Plattformunabhängigkeit">Portabilität</a> sollte bei der Entwicklung von Anwendungen auf diese Einstellung verzichtet und stattdessen alle Eingaben manuell validiert und maskiert werden, da nicht davon ausgegangen werden kann, dass auf allen Systemen dieselben Einstellungen vorherrschen oder möglich sind. Darüber hinaus sollte <code>addSlashes()</code> nicht zum Maskieren von Datenbank-Eingaben benutzt werden, da es keine ausreichende Sicherheit gegenüber <code>mysql_real_escape_string()</code> gewährleistet.<a href="#cite_note-7">[7]</a>

Nach der PHP-Version 5.3 wurde <code>mysql_real_escape_string()</code> durch <a href="MySQLi" title="MySQLi">MySQLi</a> ersetzt. Ab der Version 7.0 ist <code>mysql_real_escape_string()</code> nicht mehr verfügbar. Ab PHP 7.x heißt die Funktion <code>mysqli_real_escape_string()</code>.

Grundsätzlich sind auch in puncto Sicherheit immer Prepared Statements vorzuziehen.

Mit dem datenbankunabhängigen <a href="Modul_(Software)" title="Modul (Software)">Datenbankmodul</a> <a href="Perl-DBI" title="Perl-DBI">DBI</a>, welches normalerweise in <a href="Perl_(Programmiersprache)" title="Perl (Programmiersprache)">Perl</a> verwendet wird:

Anstatt

<div class="mw-highlight mw-highlight-lang-perl mw-content-ltr" dir="ltr"><pre>$arrayref = $databasehandle->selectall_arrayref("SELECT spalte1 FROM tabelle WHERE spalte2 = $spalte2Wert");

</pre></div>

sollte Folgendes verwendet werden:

<div class="mw-highlight mw-highlight-lang-perl mw-content-ltr" dir="ltr"><pre>$arrayref = $databasehandle->selectall_arrayref('SELECT spalte1 FROM tabelle WHERE spalte2 = ?',{},$spalte2Wert);

</pre></div>

Perls DBI-Modul unterstützt außerdem eine „prepare“-Syntax ähnlich der aus dem Java-Beispiel.

<div class="mw-highlight mw-highlight-lang-perl mw-content-ltr" dir="ltr"><pre>$statementhandle = $databasehandle->prepare("SELECT spalte1 FROM tabelle WHERE spalte2 = ?");

$returnvalue = $statementhandle->execute( $spalte2Wert );

</pre></div>

Alternativ können über das Datenbankhandle auch Eingabe-Werte sicher maskiert werden. Dabei achtet der DB-Treiber auf die für diese Datenbank typischen Sonderzeichen. Der Programmierer muss keine tiefergehenden Kenntnisse darüber haben.

$databasehandle->quote($spalte2Wert) );

</pre></div>

Im sogenannten „taint mode“, der skriptweit mit dem Parameter -T aktiviert werden kann, verwendet Perl starke Heuristiken, um nur sichere Zugriffe zu erlauben. Zeichenketten, die vom Benutzer übergebene Parameter enthalten, werden zunächst als „unsicher“ behandelt, bis die Daten explizit validiert wurden, und dürfen vorher nicht in unsicheren Befehlen verwendet werden.

<div class="mw-heading mw-heading3"><h3 id="ColdFusion_Markup_Language">ColdFusion Markup Language</h3></div>

Unter <a href="ColdFusion" title="ColdFusion">ColdFusion</a> kann das <code><cfqueryparam></code>-Tag verwendet werden, welches sämtliche notwendigen

Validierungen übernimmt:<a href="#cite_note-8">[8]</a>

<div class="mw-highlight mw-highlight-lang-cfm mw-content-ltr" dir="ltr"><pre> SELECT * FROM courses WHERE Course_ID =

</pre></div>

Über parametrisierte Kommandos kann die Datenbank vor SQL-Injections geschützt werden:

<div class="mw-highlight mw-highlight-lang-sql mw-content-ltr" dir="ltr"><pre>SELECT COUNT(*) FROM Users WHERE UserName=? AND UserPasswordHash=?

</pre></div>

<div class="mw-heading mw-heading2"><h2 id="Siehe_auch">Siehe auch</h2></div>

<ul><li><a href="Sicherheit_von_Webanwendungen" title="Sicherheit von Webanwendungen">Sicherheit von Webanwendungen</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li><a rel="nofollow" class="external text" href="http://www.erich-kachel.de/?p=223">SQL-Injections – Analyse</a></li>

<li><a rel="nofollow" class="external text" href="http://www.derkeiler.com/Mailing-Lists/securityfocus/secprog/2001-07/0001.html">Abusing Poor Programming Techniques in Webserver Scripts via SQL Injection</a> (englisch)</li>

<li><a rel="nofollow" class="external text" href="https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/WebSec/WebSec.pdf?__blob=publicationFile&v=1">Sicherheit von Webanwendungen: Maßnahmenkatalog und Best Practices</a> (PDF; 805 kB) <a href="Bundesamt_f%C3%BCr_Sicherheit_in_der_Informationstechnik" title="Bundesamt für Sicherheit in der Informationstechnik">Bundesamt für Sicherheit in der Informationstechnik</a> (BSI)</li>

<li><a rel="nofollow" class="external text" href="http://www.webappsec.org/projects/threat/v1/WASC-TC-v1_0.de.pdf">Web Security Threat Classification</a> (PDF, 432 kB)</li>

<li>Steve Friedl: <a rel="nofollow" class="external text" href="http://unixwiz.net/techtips/sql-injection.html">SQL Injection Attacks by Example.</a></li>

<li><a rel="nofollow" class="external text" href="https://www.yekta-it.de/sites/default/files/pdf/Advanced-SQL-Injection-in-MySQL-GERMAN.pdf">Advanced SQL Injection in MySQL</a> (PDF; 935 kB)</li>

<li><a rel="nofollow" class="external text" href="https://xkcd.com/327/">SQL-Injection im Comic xkcd</a> (<a href="Xkcd" title="Xkcd">xkcd.com</a>)</li>

<li><a rel="nofollow" class="external text" href="https://www.youtube.com/watch?v=8vM8b2P5uOo&list=PL4aVL6eAcvHnfoZ0aVKzQFVA0AZK7bn2f">SQLi: Videos zur Durchführung und Gegenmaßnahmen</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise_und_Ressourcen">Einzelnachweise und Ressourcen</h2></div>

<li id="cite_note-1"><a href="#cite_ref-1">↑</a> <a rel="nofollow" class="external text" href="http://dev.mysql.com/doc/refman/5.1/en/information-schema.html">Die Datenbank INFORMATION_SCHEMA.</a> MySQL 5.1 Referenzhandbuch, Kapitel 20

</li>

<li id="cite_note-2"><a href="#cite_ref-2">↑</a> <a rel="nofollow" class="external text" href="https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md">SQL_Injection_Prevention_Cheat_Sheet.md.</a> Abgerufen am 24. Oktober 2019.<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ASQL-Injection&rft.title=SQL_Injection_Prevention_Cheat_Sheet.md&rft.description=SQL_Injection_Prevention_Cheat_Sheet.md&rft.identifier=https%3A%2F%2Fgithub.com%2FOWASP%2FCheatSheetSeries%2Fblob%2Fmaster%2Fcheatsheets%2FSQL_Injection_Prevention_Cheat_Sheet.md&rft.date=">

</li>

<li id="cite_note-3"><a href="#cite_ref-3">↑</a> <a rel="nofollow" class="external text" href="http://pajhome.org.uk/blog/10_reasons_to_love_sqlalchemy.html">10 Reasons to love SQLAlchemy.</a> In: pajhome.org.uk. Abgerufen am 20. Dezember 2016.<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ASQL-Injection&rft.title=10+Reasons+to+love+SQLAlchemy&rft.description=10+Reasons+to+love+SQLAlchemy&rft.identifier=http%3A%2F%2Fpajhome.org.uk%2Fblog%2F10_reasons_to_love_sqlalchemy.html">

</li>

<li id="cite_note-4"><a href="#cite_ref-4">↑</a> <a rel="nofollow" class="external text" href="http://de.php.net/manual/de/function.addslashes.php">addslashes</a> PHP Manual

</li>

<li id="cite_note-5"><a href="#cite_ref-5">↑</a> <a rel="nofollow" class="external text" href="http://de.php.net/manual/de/function.mysql-real-escape-string.php">mysql_real_escape_string</a> PHP Manual

</li>

/* start https://de.wikipedia.org/ */

.mw-parser-output .webarchiv-memento a{color:inherit}

/* end https://de.wikipedia.org/ */

</style><a rel="nofollow" class="external text" href="https://web.archive.org/web/20210103050704/http://www.php.net/manual/de/security.magicquotes.php">Magic Quotes</a> (<a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a> des <style data-mw-deduplicate="TemplateStyles:r250917974">

/* start https://de.wikipedia.org/ */

.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}

/* end https://de.wikipedia.org/ */

</style><a class="external text" href="https://redirecter.toolforge.org/?url=http%3A%2F%2Fwww.php.net%2Fmanual%2Fde%2Fsecurity.magicquotes.php">Originals</a> vom 3. Januar 2021 im <a href="Internet_Archive" title="Internet Archive">Internet Archive</a>)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.<a rel="nofollow" class="external text" href="http://IABotmemento.invalid/http://www.php.net/manual/de/security.magicquotes.php">@1</a><a rel="nofollow" class="external text" href="http://www.php.net/manual/de/security.magicquotes.php">@2</a>Vorlage:Webachiv/IABot/www.php.net PHP Manual

</li>

<li id="cite_note-7"><a href="#cite_ref-7">↑</a> Chris Shiflett: <a rel="nofollow" class="external text" href="http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string">addslashes() Versus mysql_real_escape_string()</a> (englisch)

</li>

<li id="cite_note-8"><a href="#cite_ref-8">↑</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20061124152957/http://livedocs.macromedia.com/coldfusion/7/htmldocs/00000317.htm">ColdFusion Online-Hilfe</a> (<a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a> vom 24. November 2006 im <a href="Internet_Archive" title="Internet Archive">Internet Archive</a>)

</li>

</ol>

</div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-05-08" href="https://de.wikipedia.org/wiki/?title=SQL-Injection&oldid=255831417">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>